QuickTime Streaming

Handling Chunks Yourself

The base reassembler automatically builds chunks from packets and sends them to the stream handler you have opened. If any packets are missing from the chunk, the base reassembler discards the entire chunk.

You can take over from the base reassembler at several points in the chunk-building process by implementing the appropriate function. Do this if your reassembler performs loss recovery, or if the base reassembler's default behavior needs to be modified to correctly build chunks for the stream handler.

Your reassembler is responsible for creating and sending the chunk, beginning at whatever point you take over, and continuing until the chunk is sent or discarded.

The process of creating a chunk begins when the base reassembler has a complete packet list. To take over at this point, implement RTPRssmSendPacketList . You might want to do this if you were altering the packet list for loss recovery.

If you implement RTPRssmSendPacketList , you are responsible for deleting the packet list when you through with it by calling RTPRssmReleasePacketList .

Next, the base reassembler calculates the chunk size. It does this by summing the payload size for each packet in the list. The payload size is calculated by subtracting the RTP header and the payload header from the packet size. To take over at this point, implement RTPRssmComputeChunkSize . You might want to do this if you need to add data to the chunk that isn't in the packets, or to use a different method for calculating the payload size.

If you implement RTPRssmComputeChunkSize , you will need to allocate a chunk of the appropriate size. To do this, call RTPRssmGetChunkAndIncrRefCount . This will allocate the chunk and set the number of references to it to "1". QuickTime will maintain the chunk until the number of references to it is "0". The reference count is automatically decremented when you send the chunk. You can increment the counter by calling RTPRssmIncrChunkRefCount if you want QuickTime to preserve the chunk for later use (by substituting for a lost chunk, for example).

Once the chunk size has been calculated and the chunk has been allocated, the base reassembler moves the data from the packets into the chunk. The data moved will be a simple concatenation of the packet payloads. The payload size and offset within each packet are calculated in the same manner as used for calculating chunk size. To take over at this point, implement RTPRssmCopyDataToChunk . You would need to do this to modify the bytes at packet boundaries for an H.261 packet reassembler, for example.

Bear in mind that if you implement RTPRssmSendPacketList , you are responsible for the steps performed in RTPRssmComputeChunkSize and RTPRssmCopyDataToChunk . Similarly, if you implement RTPRssmComputeChunkSize , you must perform the steps for RTPRssmCopyDataToChunk . Only the first of these functions that you implement will be called. You take over the chunk-building process from there.

If you implement any of the three functions just discussed, you are responsible for sending the chunk by calling RTPRssmSendChunkAndDecrCount .

Other things your reassembler might do at this point are to

Tell the stream handler that the sample description has changed (RTPRssmSetSampleDescription )
Tell the stream handler that some non-media data has changed, such as a transformation matrix or sound volume (RTPRssmSendStreamHandlerChanged ). You may receive a series of GetInfo calls to determine what has changed.
Tell the stream handler not to send the chunk. The reference counter will be decremented; if it becomes zero, the chunk is deallocated (RTPRssmSendLostChunk ).
Tell the base reassembler to keep a copy of this chunk for your later use (RTPRssmIncrChunkRefCount ). Be sure to increment the ref count before you send the chunk. You must eventually call RTPRssmDecrChunkRefCount for every call to RTPRssmIncrChunkRefCount or you will create a memory leak.